-
Notifications
You must be signed in to change notification settings - Fork 47
chore: improve benchmark logic #612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| proof: Self::Proof, | ||
| ) -> Result<Self::VerificationResult, Self::Error> { | ||
| <ProviderTemplateProofVerifier as IdentityProofVerifier<Runtime>>::verify_proof_for_call_against_details( | ||
| call, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewers can skip this altogether, as it's been generated in a test setup and copy-pasted here. The unit test below is more meaningful to review.
| T::AccountId: Instanciate, | ||
| T::Identifier: Instanciate, | ||
| <<T as Config>::IdentityProvider as IdentityProvider<T>>::Success: GetWorstCase<IdentityContext<T::Identifier, T::AccountId>> | ||
| <<T as Config>::IdentityProvider as IdentityProvider<T>>::Success: GetWorstCase<IdentityContext<T::Identifier, T::AccountId>, Output = <<T as Config>::IdentityProvider as IdentityProvider<T>>::Success> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a quick fix to ensure nothing breaks with the new definition of the GetWorstCase trait. The logic can be refined in future PRs.
f49354e to
bfc7ae5
Compare
Ad96el
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Elegant solution. 3 Minor comments.
| # External dependencies | ||
| hash-db.workspace = true | ||
| log.workspace = true | ||
| cfg-if.workspace = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can also remove it from the root cargo toml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it's still used in the pallet-dip-consumer crate:
// TODO: Maybe find a nicer way to exclude the call dispatched from the
// benchmarks while making sure the call is actually dispatched and passes any
// filters the consumer proof verifier has set.
cfg_if::cfg_if! {
if #[cfg(not(feature = "runtime-benchmark"))] {
call.dispatch(did_origin.into())
} else {
().into()
}
}| const MAX_DID_MERKLE_PROOF_LEAVE_COUNT: u32 = 64, | ||
| const MAX_DID_MERKLE_PROOF_LEAVE_SIZE: u32 = 1024, | ||
| const MAX_DID_MERKLE_LEAVES_REVEALED: u32 = 64, | ||
| const MAX_PROVIDER_HEAD_PROOF_LEAVE_COUNT: u32 = DEFAULT_MAX_PROVIDER_HEAD_PROOF_LEAVE_COUNT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intended to increase the MAX_PROVIDER_HEAD_PROOF_LEAVE_COUNT from 64 to 128? Same for the others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I noticed every proof I generated was larger than 64, so I bumped it up to the next power of 2. These are anyway default values, can be overridden by specific consumers.
| ConsumerBlockNumber, | ||
| >, | ||
| ) -> Self { | ||
| Self::V0(value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if a new version is introduced? Is there a way to distinguish them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a new version is introduced, it will be because of a breaking change, so they will be different from each other. Otherwise if they cannot be distinguished, why would they be different in their versions?
Changing the storage hasher before we deploy on production, otherwise we would then need a migration strategy. I think we can disregard any migrations on our testnets, as the effort is not justified. I also lowered the limits of the DIP provider template, which were higher than Peregrine, so that it is faster to generate the benchmark worst case. Related to #601, based on top of #612.
Partially fixes https://github.com/KILTprotocol/ticket/issues/2562. Adds unit tests for the verifier components (components tested are shown in the checklist below). It also splits up the proof verification logic into multiple files, split by when those checks are performed. Check the `crates/kilt-dip-primitives/src/merkle/v0/` folder for more details. It addresses an open comment in the DIP refactoring PR: #602 (comment). ## Elements to add tests for - [x] `pallet-dip-consumer` - [x] `pallet-relay-store` - [x] `ProofVerifier` - [x] Merge #612 - [x] Merge #613
Partially fixes https://github.com/KILTprotocol/ticket/issues/2562. Adds unit tests for the verifier components (components tested are shown in the checklist below). It also splits up the proof verification logic into multiple files, split by when those checks are performed. Check the `crates/kilt-dip-primitives/src/merkle/v0/` folder for more details. It addresses an open comment in the DIP refactoring PR: #602 (comment). ## Elements to add tests for - [x] `pallet-dip-consumer` - [x] `pallet-relay-store` - [x] `ProofVerifier` - [x] Merge #612 - [x] Merge #613
Partially fixes https://github.com/KILTprotocol/ticket/issues/2562. Adds unit tests for the verifier components (components tested are shown in the checklist below). It also splits up the proof verification logic into multiple files, split by when those checks are performed. Check the `crates/kilt-dip-primitives/src/merkle/v0/` folder for more details. It addresses an open comment in the DIP refactoring PR: #602 (comment). ## Elements to add tests for - [x] `pallet-dip-consumer` - [x] `pallet-relay-store` - [x] `ProofVerifier` - [x] Merge #612 - [x] Merge #613
Partially fixes https://github.com/KILTprotocol/ticket/issues/2562. Adds unit tests for the verifier components (components tested are shown in the checklist below). It also splits up the proof verification logic into multiple files, split by when those checks are performed. Check the `crates/kilt-dip-primitives/src/merkle/v0/` folder for more details. It addresses an open comment in the DIP refactoring PR: KILTprotocol/kilt-node#602 (comment). ## Elements to add tests for - [x] `pallet-dip-consumer` - [x] `pallet-relay-store` - [x] `ProofVerifier` - [x] Merge KILTprotocol/kilt-node#612 - [x] Merge KILTprotocol/kilt-node#613
Partially fixes https://github.com/KILTprotocol/ticket/issues/2562. Adds unit tests for the verifier components (components tested are shown in the checklist below). It also splits up the proof verification logic into multiple files, split by when those checks are performed. Check the `crates/kilt-dip-primitives/src/merkle/v0/` folder for more details. It addresses an open comment in the DIP refactoring PR: KILTprotocol/kilt-node#602 (comment). ## Elements to add tests for - [x] `pallet-dip-consumer` - [x] `pallet-relay-store` - [x] `ProofVerifier` - [x] Merge KILTprotocol/kilt-node#612 - [x] Merge KILTprotocol/kilt-node#613
Fixes https://github.com/KILTprotocol/ticket/issues/3104, based on top of #611.
It fixes the logic for the
dip-consumerpallet, by delegating the generation of a proof worst case to the proof verifier, which must make sure the proof is indeed the one that requires the most weight to verify, and that it verifies successfully. This also means that each consumer runtime is responsible to implement this method, as there cannot be a "universal" worst proof, as that depends on the use case. The pallet benchmarking logic is now generic enough to make this possible and flexible ✨✨✨